-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cache): Add Cache-Control: no-cache
support for Loki instant queries.
#12896
Conversation
40eb3ed
to
1b77ecf
Compare
Goal is, if that header is set, we gurantee that response user got for that query is never from results cache. Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
8ad5cd3
to
12a591a
Compare
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
Cache-Control: no-cache
support for Loki queries.Cache-Control: no-cache
support for Loki instant queries.
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. just a couple of nits
rc.put(ctx, key, []Extent{mkExtent(int64(modelNow)-(600*1e3), int64(modelNow))}) | ||
|
||
// Asserts (when `shouldCacheReq` is non-nil and set to return false (should not cache), resultcache should get result from upstream handler (mockHandler)) | ||
// 1. With `shouldCacheReq` non-nil and set `noCacheReq`, should get result from `next` handler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we change this shouldCacheReq
to shouldLookupCache
or bypassCache
?
the current name is a bit confusing, it reads "whether this request should be cached"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. I can change it in my tests. But the original type still called ShouldCacheReq
(IMO, still confusing, because the same request's results can still be cached after getting it from the upstream).
Should ideally be called something like ShouldLookupCache
. I will fix the naming on my test now. Renaming the original type I can do it in separate PR may be.
|
||
// fill cache | ||
key := ConstSplitter(day).GenerateCacheKey(context.Background(), "1", req) | ||
rc.put(ctx, key, []Extent{mkExtent(int64(modelNow)-(600*1e3), int64(modelNow))}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could be flaky at times, because the extent might end up in the previous day when this test runs on a day boundary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we could use constant time range similar to other tests to keep this predictable? mkExtent(50, 120)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extent should be irrelevent here I think because, the test is make sure we are calling upstream next
handler instead of looking up in the cache in the first place (independent of cache hit or cache miss).
But good idea to make it constant anyway. Will update it.
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
What this PR does / why we need it:
Goal is, if header
Cache-Control: no-cache
is set, we guarantee that response user got for that query is never from the results cache.Two changes at high-level
Cache-Control
header and bypass the results if the value isno-cache
.--nocache
to support setting the right header when sending queries to Loki.Changes in Action:
Hitting the results cache from the following log lines in Loki
Not hitting the results cache from the following logs in Loki
Which issue(s) this PR fixes:
Fixes NA
Special notes for your reviewer:
This PR adds support only for
instant
queries now. Follow up PRs will support for all types of queries.Instant queries uses
downstream
engine viasplit_by_range
middleware. Which convertsLokiInstantRequest
toParams
and convert back from Params toLokiInstantRequest
. So added support to persist cachingOptions in params as well.Since this header is only valuable for Query-frontend, we don't persist this header when passing the subqueries to the querier (via HTTP -> GRPC -> HTTP roundtrip).
Checklist
CONTRIBUTING.md
guide (required)feat
PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.docs/sources/setup/upgrade/_index.md
production/helm/loki/Chart.yaml
and updateproduction/helm/loki/CHANGELOG.md
andproduction/helm/loki/README.md
. Example PRdeprecated-config.yaml
anddeleted-config.yaml
files respectively in thetools/deprecated-config-checker
directory. Example PR